关系型SQL与stream processing对比如下：

      Materialized View被定义为一条SQL查询，其会缓存查询结果。但当所查询的表(基表)被修改时，缓存的结果将过期。·       Eager View Maintenance会更新Materialized View，当基表被更新时，会立刻更新Materialized View中缓存的结果。       Eager View Maintenance和SQL Query在streams上的关系如下：       ① 数据库表是INSERT、UPDATE、DELETE等DML语句流的结果，被流称为changelog stream。       ② Materialized View被定义为一条SQL查询。为更新View，查询需要不断处理changelog stream。       ③ Materialized View是streaming SQL查询结果。

      动态表是Flink流上Table API & SQL的核心概念，其随时间动态变化；       ① 查询动态表会产生一个连续查询；       ② 连续查询永不停止，其会产生一个动态表；       ③ 当所查询的动态表发生变化时，查询会更新结果动态表。 连续查询的结果等同在输入表的快照上以批处理模式执行相同查询的结果。       流、动态表、连续查询的关系如下图所示：

      ① 流将转换为动态表；       ② 在动态表上评估连续查询，生成新的动态表；       ③ 生成的动态表将转换回流。       注意：动态表首先是一个逻辑概念。在查询执行过程中不一定（完全）实现动态表。在在下文中，本文将通过具有以下模式的单击事件流来解释动态表和连续查询的概念：

      为了使用关系查询处理流，必须将其转换为Table。从概念上讲，流的每个记录都被解释为INSERT对结果表的修改。本质上，本文是从INSERT仅changelog流构建表。       下图可视化了click事件流（左侧）如何转换为表格（右侧）。随着插入更多点击流记录，结果表将持续增长。

      连续查询作用于动态表并又会产生动态表了连续查询不会终止并会根据其输入表（动态表）上的更新来更新其结果表（动态表）。       下面显示在点击事件流上定义的clicks表上显示两个查询示例。       首先是GROUP BY COUNT聚合查询示例。

      当查询开始时，clicks表为空；当第一行插入到clicks表中时，查询开始计算结果表（动态表），如[Mary,./home]插入后，结果表包含一行结果[Mary，1]；当插入第二行[Bob,./cart]时，查询会更新结果表并插入新纪录[Bob,1]。第三行[Mary,./prod=id=1]插入时，查询会更新结果表中的[Mary,1]记录，将其更新为[Mary,2]。最后一行[Liz,1]插入clicks表后，也会更新到结果表（插入新纪录）。       第二个查询与第一个查询类似，除了用户属性之外，还在小时滚动窗口上对clicks表进行分组，然后对URL进行计数（基于时间的计算，如窗口基于特殊的时间属性）。

      每个小时查询会计算结果并更新结果表。当cTime在12:00:00-12:59:59之间，clicks表存在四条记录，对应的查询计算出两条结果；下个时间窗口(13:00:00-13:59:59)，clicks表中存在三条记录，对应的查询计算出两条结果添加值结果表中；当记录插入至clicks表中后，结果表也会被动态更新。 （1）更新和附加查询       上述两个查询虽然有些类似（均计算统计聚合分组），但两者也有显著不同：第一个查询会更新结果表的结果，如定义在结果表上的changelog流包含INSERT和UPDATE；第二个查询仅仅往结果表中添加记录，如定义在结果表上的changelog流只包含INSERT。一个查询是否生成仅插入表转化为流与更新表转化为流不同。 （2）查询限制       很多查询可以等同在流上的连续查询，一些查询由于需维护状态的大小或计算更新代价大导致查询计算代价太大。       状态大小：无界限流上的连续查询经常会运行数周或数月。因此，连续查询处理的数据总量可以很大，需要以前结果(结果表)的连续查询需要维护所有行以便进行更新。例如，第一个查询示例中需要保存每个user的url的count以便可以增加count，使得当输入表(左侧表)接收一行新数据时会产生新的结果(右侧表)。若只跟踪注册用户，那么维护cnt大小代价不会太大(注册用户量不太大)。但若非注册用户也分配唯一的用户名，则随着时间的增加，维护cnt大小代价将增大，最终导致查询失败。

      计算更新：即使只添加或更新单行记录，一些查询需要重新计算和更新大部分结果行，通常这样的查询不适合作为连续查询。如下查询示例中，会根据最后一次点击的时间为每个用户计算RANK。一旦clicks表收到新行，用户的lastAction被更新并且应该计算新的RANK。然而由于不存在两行相同RANK，所以所有较低RANK的行也需要被更新。